Systems of multiple distributed ledgers using cross-ledger transfers for highly-scalable transaction throughput

ABSTRACT

The presently-disclosed solution provides cross-ledger transfers between distributed ledgers to achieve highly-scalable transaction throughput. Disclosed are methods and instruction code for writing a cross-ledger transfer in a way that effectively transfers value from a source distributed ledger to a target distributed ledger while preventing double spending of the value. This results in the transformation of the ledgers in that the total value in the source ledger is decreased by the transferred value while the total value in the target ledger is increased by the same amount. Also disclosed are system architectures that utilize cross-ledger transfers between multiple distributed ledgers to achieve highly-scalable transaction throughput. Also disclosed are computer apparatus configured to implement cross-ledger transfers between distributed ledgers. Other embodiments and features are also disclosed.

CROSS-REFERENCE TO RELATED APPLICATION(S)

The present application claims the benefit of U.S. Provisional PatentApplication No. 62/607,453, filed Dec. 19, 2017, entitled “BlockchainEcosystem Using Multiple Blockchains and Cross-Chain Transactions toAchieve Highly-Scalable Transaction Throughput,” the disclosure of whichis hereby incorporated by reference. The present application is relatedto U.S. patent application Ser. No. ______ (attorney docket no.10062.000110), filed on even date herewith, entitled “Cross-LedgerTransfers Between Distributed Ledgers,” the disclosure of which ishereby incorporated by reference. The present application is alsorelated to U.S. patent application Ser. No. ______ (attorney docket no.10062.000130), filed on even date herewith, entitled “Computer Apparatusfor Cross-Ledger Transfers Between Distributed Ledgers,” the disclosureof which is hereby incorporated by reference.

BACKGROUND 1. Field of the Invention

The present disclosure relates generally to computer and networktechnology. More particularly, the present disclosure relates toblockchain and other distributed ledger technologies.

2. Description of the Background Art

A blockchain is a chain of block data structures (blocks) that isaccessed and validated by a blockchain network. One example of ablockchain is known as the BITCOIN blockchain which functions as adistributed ledger of BITCOIN transactions, where BITCOIN is a specificcryptocurrency. Each block in the BITCOIN blockchain encodes multipletransactions of BITCOINs.

In the BITCOIN blockchain, each block includes a block header and a rootof the Merkle tree of hash values for transactions included in theblock. Each block is identified by a block hash (which is a hash valueof the block header). The block header includes the root of the block'sMerkle tree, the block hash of the previous block in the chain, and anonce. A new block of transactions may be added to the BITCOINblockchain by a miner in the BITCOIN network. Miners may access theblockchain and receive broadcasts of new transactions. A new block maybe added to the blockchain when a miner validates the transactions in aprospective block and satisfies a challenge. A consensus protocolprotects the consistency and integrity of the BITCOIN blockchain.

SUMMARY

The transaction throughput of conventional distributed ledgertechnologies has significant limitations and is not readily scalable.For example, the BITCOIN blockchain network has highly problematicthroughput limitations due to latency and bandwidth issues, along withblock size limits. It is highly desirable to solve the throughputscalability problem of distributed ledger technology.

The presently-disclosed solution provides cross-ledger transfers betweendistributed ledgers to achieve highly-scalable transaction throughput.Disclosed are methods and instruction code for writing a cross-ledgertransfer in a way that effectively transfers value from a source to atarget distributed ledger while preventing double spending of the value.Also disclosed are system architectures that utilize cross-ledgertransfers between multiple distributed ledgers to achievehighly-scalable transaction throughput. Also disclosed are computerapparatus configured to implement cross-ledger transfers betweendistributed ledgers.

The cross-ledger transfer of the presently-disclosed solution results inthe transformation or modification of the ledgers in that the totalvalue in the source ledger is decreased by the transferred value whilethe total value in the target ledger is increased by the same amount. Inan exemplary implementation, the extinction of the transferred value inthe source ledger and the re-creation of the transferred value in thetarget ledger may be accomplished using a locking transaction in thesource ledger and initiating and completing transactions in the targetledger. The locking transaction references the initiating transaction,and the completing transaction references the locking transaction andspends a transaction output of the initiating transaction.

One embodiment of the presently-disclosed invention relates to a methodof performing a cross-ledger transfer which transfersdigitally-represented economic value from a source distributed ledger toa target distributed ledger in a way that prevents double spending ofthat value. An initiating transaction is written to the targetdistributed ledger, and a locking transaction is written to the sourcedistributed ledger. The locking transaction spends a transaction outputof an existing transaction in the source distributed ledger andreferences the initiating transaction in the target distributed ledger.A completing transaction may then be written to the target distributedledger. The completing transaction spends the transaction output of theinitiating transaction and references the locking transaction in thesource distributed ledger.

Another embodiment relates to a non-transitory tangible medium withcomputer-readable code to perform a cross-ledger transfer. Thecross-ledger transfer transfers digitally-represented economic valuefrom a source distributed ledger to a target distributed ledger in a waythat prevents double spending of that value.

Another embodiment relates to a first system architecture that usescross-ledger transfers between distributed ledgers to achievehighly-scalable transaction throughput. The first system architectureincludes a plurality of distributed ledger networks, each saiddistributed ledger network including a plurality of payment verificationnodes for other distributed ledgers in the system.

Another embodiment relates to a second system architecture that usescross-ledger transfers between distributed ledgers to achievehighly-scalable transaction throughput. The second system architectureincludes a plurality of distributed ledger networks. The second systemarchitecture further includes a set of shared nodes that are shared bythe plurality of distributed ledger networks. Said shared nodes areprovide, among other services, inter-ledger verification oftransactions.

Another embodiment relates to a first computer apparatus forcross-ledger transfers between a plurality of distributed ledgers. Thefirst computer apparatus includes computer-readable code for a localnode-stack for a local distributed ledger of the plurality ofdistributed ledgers and computer-readable code for a foreign paymentverification node-stack for a foreign distributed ledger of theplurality of distributed ledgers. The local node-stack is configured touse the foreign payment verification node-stack to verify transactionsin the foreign distributed ledger during a cross-ledger transfer of adigitally-represented economic value between the local and foreigndistributed ledgers.

Another embodiment relates to a second computer apparatus forcross-ledger transfers between a plurality of distributed ledgers. Thesecond computer apparatus includes computer-readable code fornode-stacks of the plurality of distributed ledgers. Each saidnode-stack is configured to perform a cross-ledger transfer of adigitally-represented economic value from a source distributed ledger toa target distributed ledger.

Other embodiments and features are also disclosed.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram depicting the structure of a single distributedledger network in accordance with an embodiment of the presentinvention.

FIG. 2 is a diagram depicting data components of a single-transactioncross-ledger transfer of digitally-represented economic value betweensource and target distributed ledgers in accordance with an embodimentof the present invention.

FIG. 3 is a diagram depicting a two-transaction cross-ledger transferwhich involves a mint transaction in a target distributed ledger whichreferences a mint license granting transaction in a source distributedledger in accordance with an embodiment of the present invention.

FIG. 4 is a diagram depicting a three-transaction cross-ledger transferof digitally-represented economic value from a source distributed ledgerto a target distributed ledger in accordance with an embodiment of thepresent invention.

FIG. 5A is a diagram depicting a system architecture which uses foreignpayment verification (PV) nodes for performing cross-ledger transfers inaccordance with an embodiment of the present invention.

FIG. 5B is a diagram depicting a computer apparatus for a node in thesystem architecture of FIG. 5A in accordance with an embodiment of thepresent invention.

FIG. 5C is a diagram depicting a chain of block headers and blocksignatures used by a foreign PV node in accordance with an embodiment ofthe present invention.

FIG. 6A is a diagram depicting a system architecture which uses nodesshared by multiple distributed ledger networks for performingcross-ledger transfers in accordance with an embodiment of the presentinvention.

FIG. 6B is a diagram depicting a computer apparatus for a shared node inthe system architecture of FIG. 6A in accordance with an embodiment ofthe present invention.

FIG. 7 is a flow chart of a method for an owner of adigitally-represented economic value on a source distributed ledger totransfer the digitally-represented economic value to an entity on atarget distributed ledger in accordance with an embodiment of thepresent invention.

FIG. 8 shows a process for inter-ledger transaction verification inaccordance with an embodiment of the present invention.

FIG. 9 shows pseudocode for a procedure that may be performed toinitiate a cross-ledger transaction from a source distributed ledger toa target distributed ledger in accordance with an embodiment of thepresent invention.

FIG. 10 shows pseudocode for a procedure that may be performed after aninitiating or a locking transaction is committed in accordance with anembodiment of the present invention.

FIG. 11 shows pseudocode for a procedure that may be performed to commita transaction on a foreign distributed ledger in accordance with anembodiment of the present invention.

FIG. 12 shows pseudocode for a procedure that may be performed to submita transaction to a distributed ledger in accordance with an embodimentof the present invention.

FIG. 13 shows pseudocode for a procedure that may be performed by nodesof a distributed ledger after consensus on a block of transactions isreached in accordance with an embodiment of the present invention.

FIG. 14 shows pseudocode for a procedure that may be performed by nodesof a distributed ledger to index unspent transaction outputs in blocksthat have been committed in accordance with an embodiment of the presentinvention.

FIG. 15 shows a general structure for a standard transaction whichincludes a cross-ledger referenced transaction input accordance with anembodiment of the present invention.

FIG. 16 shows a structure for an initiating transaction of athree-transaction cross-ledger transfer in accordance with an embodimentof the present invention.

FIG. 17 shows a structure for a locking transaction of athree-transaction cross-ledger transfer in accordance with an embodimentof the present invention.

FIG. 18 shows a structure for a completing transaction of athree-transaction cross-ledger transfer in accordance with an embodimentof the present invention.

FIG. 19 is a graph showing the calculated transaction throughput perledger as a function of the number of distributed ledgers in the systemin accordance with an embodiment of the present invention.

FIG. 20 is chart showing the calculated aggregate transaction throughputas a function of the number of distributed ledgers in accordance with anembodiment of the present invention.

FIG. 21 is a diagram depicting, at a high level, components of acomputer system in accordance with an embodiment of the presentinvention.

The use of the same reference label in different drawings indicates thesame or like components.

DETAILED DESCRIPTION Introduction

Conventionally, institutions rely on a central clearing house to handleclearance and settlement of financial transactions. Such conventionalclearance and settlement is problematic in that it is time consuming andexpensive, particularly for international transactions.

In recent years, however, an alternative means for clearance andsettlement has become available. This alternative generally uses adistributed ledger to clear and settle transactions in a cryptographiccurrency. A notable example of such a cryptographic currency is BITCOINwhich is maintained by the BITCOIN blockchain network. Other examples ofcryptographic currencies include LITECOIN, NOVACOIN, NAMECOIN, DOGECOIN,PEERCOIN, ETHEREUM, and RIPPLE.

FIG. 1 is a diagram depicting the structure of a single distributedledger network 100 in accordance with an embodiment of the invention.The distributed ledger network 100 may be used to maintain a distributedledger of transactions. One example of a distributed ledger is theBITCOIN blockchain. However, the distributed ledger network 100 may begenerally any blockchain network or may be another type of distributedledger network, such as one that uses a directed acyclic graph (DAG)algorithm to provide a DAG-based ledger. The presently-disclosedsolution is generally applicable to (compatible with) a distributedledger that is implemented using block of transactions, where each blockheader has a Merkle root of the transactions contained in the block.

The distributed ledger network 100 includes a plurality of nodes 102with communicative connections 104 therebetween. For purpose of ease ofillustration, only several nodes 102 are shown in the figure, but thedistributed ledger network 100 may have a very large number of nodeswith various interconnections 104 therebetween.

The nodes 102 generally each contain a complete and up-to-date copy ofthe data of the distributed ledger and so may be referred to as fullnodes. In the example of the BITCOIN network, such full nodes mayoperate as miners of the BITCOIN blockchain, where successful miners arepaid in the digital currency of BITCOIN. However, in accordance with anembodiment of the present invention, a distributed ledger may not needto pay successful miners in a digital currency and, furthermore, maydeal more generally with digitally-represented assets (or liabilities)which need not be in a cryptocurrency.

A plurality of clients 106 may be communicatively connected to thedigital ledger network 100. These clients 106 are lightweight nodes inthat they do not maintain a complete and up-to-date copy of thedistributed ledger, but they still have the capability to verifytransactions in the distributed ledger.

For example, the clients 106 may be implemented as payment verification(PV) nodes which may verify transactions using a payment verificationmethod. A PV node may be a non-full node that is connected to thedistributed ledger network and holds the data required to prove thevalidity of a transaction in the distributed ledger. Individualtransaction records are generally missing from the data at a PV node, sothe PV node may be considered to be a client of a distributed ledgernetwork. In an exemplary implementation, when the distributed ledger isa blockchain, the PV node may be a simplified payment verification (SPV)node, and the required data includes a Merkle root of the transactionsin the block, the previous block hash, and a list of block signaturescreated by block validators.

The clients 106 may be considered to form part of an extended networkbeyond the core distributed ledger network. While only a few clients 106are shown for ease of illustration, a multitude of clients 106 may beconnected to the distributed ledger network 100.

As mentioned above, a famous example of a distributed ledger is ablockchain. A blockchain is maintained by a peer-to-peer (P2P) networkof nodes running a P2P protocol to reach consensus serially on blocks oftransactions. The presently-disclosed solution may be generally appliedto blockchain technology or to other distributed ledger technologies.

A transaction in the distributed ledger may include a list of inputs anda list of outputs. A transaction hash may be constructed by hashing allof the data within a transaction. A transaction hash may be used toreference a transaction (i.e. as a transaction identifier or tx id).

A transaction output (TXO) may be identified by the hash of itstransaction, its index within the transaction, and an identification ofthe recipient of the TXO. A TXO may hold any digitally-representedasset. TXOs are not transferred; the digitally-represented economicvalues within TXOs are transferred. The recipient may be identified bythe hash of a public key of the recipient (who has the correspondingprivate key).

A transaction input references a TXO. For a conventional intra-ledgertransaction, a transaction input references a TXO by the transactionhash and output index of the TXO. As taught by the present disclosure,the transaction input 210 for a cross-ledger transaction may be asdescribed below in relation to FIG. 2.

Transaction Throughput Limitations

A conventional distributed ledger network, such as the BITCOIN network,has substantial transaction throughput limitations. These limitationsare due to latency and bandwidth issues, along with limits to the blocksize.

Once a new block is created, it must be propagated throughout thedistributed ledger network. However, there are substantial minimumlatencies between authoritative network nodes (i.e. validator nodes)that are in different parts of the world. These latencies provide alower limit to the speed of propagation and so limit the transactionthroughput.

In addition, in order to increase transaction throughput, it may bepossible to increase block size so as to fit in more transactions perblock, and/or it may be possible to increase block frequency so as toprocess more blocks. However, bandwidth limitations within thedistributed ledger network generally limits throughput gains achievableby such increases in block size and/or block frequency.

Multiple Distributed Ledger System with Cross-Ledger Transfers

The present disclosure provides an innovative solution to overcome theabove-discussed transaction throughput limitations of a conventionaldistributed ledger technologies. Disclosed is technology that provides amultiple distributed ledger system with cross-ledger transfers. Thecross-ledger transfers enable digitally-represented economic value to betransferred from one distributed ledger to another distributed ledger.

An example of digitally-represented economic value is a cryptocurrency,such as BITCOIN in the BITCOIN blockchain. More generally, thedigitally-represented economic value transferred between source andtarget distributed ledgers may be any digitally-represented asset (suchas conventional currency, cryptocurrency, a commodity, or otherproperty) or liability (such as a debt). In one embodiment, thedigitally-represented economic value may be in an amount of currency. Inanother embodiment, the digitally-represented economic value may be inan amount of cryptocurrency. In another embodiment, thedigitally-represented economic value may be an amount of a commodity.

The cross-ledger transactions may be used to, in effect, link togetherthe multiple distributed ledgers of the system. As such, the integrityof the transactions in each distributed ledger depends upon theintegrity of the transactions in the other linked distributed ledger(s).

When multiple distributed ledgers are effectively linked together bycross-ledger transactions, the system of linked-together distributedledger networks may be referred to as a multiple distributed ledgersystem or a distributed ledger “ecosystem”. The distributed ledgersbeing maintained by the multiple distributed ledger system cooperatewith each other and may be referred to as “co-ledgers”.

While co-ledgers are each part of a same overall system, each co-ledgeris a separate or “foreign” distributed ledger in relation to the otherco-ledgers. Each co-ledger maintains its own ledger of transactions, andits ledger does not include transactions of the other co-ledgers.However, a transaction in one co-ledger may reference a transaction in adifferent co-ledger.

Advantageously, as disclosed herein, a multiple distributed ledgersystem having a scalable number of co-ledgers may be applied to overcomethe above-discussed throughput limitations of a single distributedledger network.

The latency limitation may be overcome because, when two validator nodeshave a long latency between them, then they may be separated intodistinct distributed ledger networks within the system. Since the twonodes validate different ledgers, the long latency between them will notaffect the consensus time of either ledger. Hence, thepresently-disclosed solution may be used to substantially reduce oreliminate the effect on performance of long latencies between nodes.

The bandwidth limitation may be overcome because the block size may beeffectively reduced by using multiple co-ledgers, instead of a singledistributed ledger. A structure with N co-ledgers may be used toeffectively reduce the block size by a factor on the order of 1/N.

Thus, by dividing nodes into regions (or groups) such that cross-ledgertransactions are relatively rare, the added throughput from adding aco-ledger will be a substantial fraction of the full throughput of justthat chain running alone. This should result in an approximately linearthroughput scaling with the number of co-ledgers.

Cross-Ledger Transaction Between Co-Ledgers

In accordance with an embodiment of the invention, a cross-ledgertransaction between two distributed ledgers (i.e. two “co-ledgers”)effectively extinguishes an existing unspent transaction output (UTXO)on the source distributed ledger 200S and creates one or more new UTXOs(with a total value equal to the extinguished UTXO) in the targetdistributed ledger 200T. Components of a cross-ledger transaction 205that are written into the target distributed ledger 200T are depictedFIG. 2 in accordance with an embodiment of the invention.

As depicted in FIG. 2, the cross-ledger transaction 205 (which is to bewritten into the target distributed ledger 200T) comprises a transactioninput 210, that provides references into the source distributed ledger200S and a transaction output (or outputs) 220 which transfer value (orvalues) to a recipient (or recipients) in the target distributed ledger200T.

More specifically, the transaction input 210 may include the chainidentifier 211 of the source distributed ledger 200S, the block header212 for the block for the existing transaction being referenced(including the Merkle branch hashes 214 for the Merkle tree of theblock), the existing transaction being referenced 213, and the outputindex 215 which comprises a number that indicates the specific output ofthe existing transaction.

Note that the number of Merkle branch hashes 214 required is greaterthan, or equal to, a base 2 logarithm of the number of transactions inthe block. Hence, if there are 1000 (one thousand) transactions in theblock, then 10 (ten) Merkle branch hashes are required.

Note also that the transaction hash (which may be referred to as atransaction identifier or tx id) is a hash value derived from thereferenced transaction 213 by applying a hash function to the contentsof the referenced transaction. The transaction hash may be hashed withthe Merkle branch hashes to form a Merkle root. This Merkle root may bematched against the Merkle root of the block within the sourcedistributed ledger 200S to prove the transaction 213 exists in thesource distributed ledger 200S.

The transaction output or outputs 220 provide the data for the spendingof the that was obtained from the UTXO in the source distributed ledger200S (as specified by the transaction 213 and the output index 215).Each transaction output 220 provides a digitally-represented economicvalue which has been transferred to a recipient and a hash of the publickey of the recipient.

Two-Transaction Cross-Ledger Transfer Which Prevents Spending in theSource Distributed Ledger

To understand the mechanism of operation of the disclosed method forperforming a cross-ledger transfer of digitally-represented economicvalue, consider minting through a referenced transaction as depicted inFIG. 3. In FIG. 3, the minting of digitally-represented economic valuein a target distributed ledger (for example, a target blockchain) isperformed through a referenced transaction in a source distributedledger (for example, a source blockchain). However, as discussed below,such minting of digitally-represented economic value as depicted doesnot include a mechanism for preventing double (multiple) spending of thetransferred value.

Consider that a transaction output (TXO) in a referenced transaction isguaranteed to have existed sometime in the past, but it is notguaranteed to still be unspent (at the current time or in the future).This means that referencing a TXO in the source chain is insufficient tosupport a cross-ledger transaction because only an unspent TXO (i.e. aUTXO) must be referenced.

In the cross-ledger transfer depicted in FIG. 3, the mint licensegranting transaction 302 in a source distributed ledger is a transactionthat, by definition, will never be granted to another minter in thesource distributed ledger. Hence, the TXO from the mint license grantingtransaction 302 is essentially unspendable in the source distributedledger. In this case, using a Merkle proof 304 to prove the presence ofthe transaction granting the mint license in the source chain sufficesto prove that the TXO is unspent (because it is unspendable) in thesource distributed ledger.

As such, the fact that the mint license granting transaction exists inthe source distributed ledger provides a basis for the mint transaction306 to mint digitally-represented economic value in the targetdistributed ledger. Thereafter, the minted value may be used normally308 for transactions in the target distributed ledger.

However, while the two-transaction cross-ledger transfer of FIG. 3 issafely avoids double spending when all entities using the system aretrusted, it is insufficient to prevent double spending when untrustedentities may use the system. This is because the two-transactioncross-ledger transfer of FIG. 3 does not prevent the unspent TXO in thesource distributed ledger from being spent in more than one targetdistributed ledger.

Three-Transaction Cross-Ledger Transfer which Prevents Double Spending

In accordance with an embodiment of the invention, the method 400depicted in FIG. 4 transfers digitally-represented economic valuebetween co-ledgers. The cross-ledger transfer is performed in a waywhich guarantees, via a series of handshakes, that the value cannot becreated out of nowhere by spending the unspent value in the sourcedistributed ledger in more than one target distributed ledger.

As shown in FIG. 4, an exemplary implementation of such a cross-ledgertransfer may generate and commit a series of three individualtransactions to the distributed ledgers of the system. Thesetransactions include an initiating transaction in the target distributedledger; a locking transaction in the source distributed ledger; and acompleting transaction in the target distributed ledger.

In a first stage of the method 400 which transfers digitally-representedeconomic value between co-ledgers, an unspent transaction output (UTXO)of an existing transaction 402 in the source distributed ledger 200S isfound or identified. It is this UTXO in the source distributed ledgerthat is to be spent in the target distributed ledger 200T.

In a second stage of the method 400, an initiating transaction 404 isgenerated and committed to the target distributed ledger 200T. Theinitiating transaction 404 creates the same digitally-representedeconomic value as the identified UTXO of the existing transaction 402.However, in accordance with an embodiment of the invention, theinitiating transaction 404 has a special property in that its outputcannot be spent in a normal manner. (More particularly, as discussedbelow, the UTXO of the initiating transaction 404 can only be spent by acompleting transaction 408 that references the locking transaction 406which references the initiating transaction 404 and spends theidentified UTXO of the existing transaction 402.)

In a third stage of the method 400, after the initiating transaction 404is committed to the target distributed ledger 200T, a lockingtransaction 406 is generated and committed to the source distributedledger 200S. The transaction input of the locking transaction 406 is theidentified UTXO of the existing transaction 402 in the sourcedistributed ledger 200S. As such, the locking transaction 406 spends theidentified UTXO of the existing transaction 402 so that output becomes aspent TXO (and so no longer spendable) in the source distributed ledger200S. However, by definition of the locking transaction, its output isunspendable (i.e. its output can never be spent). In effect, the lockingtransaction 406 locks the identified UTXO of the existing transaction402 such that it is never spent in the source distributed ledger 200S.

Furthermore, the locking transaction 406 references the initiatingtransaction 404 in the target distributed ledger 200T (for example, byproviding the entire initiating transaction and the Merkle root andbranch hashes for verifying the existence of the initiating transactionin the target block). This “Merkle reference” from the lockingtransaction 406 to the initiating transaction 404 is used to prevent thevalue of the identified UTXO from being spent by more than once.

In a fourth stage of the method 400, after the locking transaction 406is committed to the source distributed ledger 200S, a completingtransaction 408 is generated and committed to the target distributedledger 200T. A valid completing transaction 408 spends the UTXO createdby the initiating transaction 404.

In order to be valid, the completing transaction 408 must reference thelocking transaction 406 (for example, by providing the entire lockingtransaction and the Merkle root and branch hashes that may be used toverify the existence of the locking transaction in the source block)which spent the identified UTXO. Because the output of the lockingtransaction 406 cannot be spent, the existence of the lockingtransaction 406 in the source distributed ledger 200S provides aguarantee that the identified UTXO has been, in effect, extinguished inthe source distributed ledger 200S.

More than one completing transaction 408 cannot be committed. This isbecause the completing transaction 408 is only valid if it spends (byway of its transaction input) the UTXO of the initiating transaction 404which is referenced by the locking transaction 406. Hence, if the outputbeing spent by the completing transaction 408 is not the output of theinitiating transaction 404 referenced by the locking transaction 406,then the completing transaction 408 is invalid and so is prevented frombeing committed to the target distributed ledger 200T.

The transaction output or outputs (TXO or TXOs) of a valid completingtransaction 408 represents the completion of the cross-ledgerdigitally-represented economic value transfer to one or more recipientsin the target distributed ledger 200T. The TXO or TXOs of the completingtransaction 408 may be spent normally within the target distributedledger 200T by the recipient or recipients. In other words, once thecompleting transaction is committed to the target distributed ledger,the TXO(s) of the completing transaction may be spent within the targetdistributed ledger without needing to further reference any transactionin the source distributed ledger.

System Architectures

One system architecture that may be used to support cross-ledgertransfers may have each full node of the source distributed ledger alsobe a full node of the target distributed ledger. Although such afull-overlapping system architecture would support cross-ledgertransfers, it would require substantial extra resources at each node.

Disclosed herein are exemplary system architectures which supportcross-ledger transfers while requiring less resources than afully-overlapping system architecture. A first exemplary systemarchitecture embeds foreign payment verification (PV) nodes intodistributed ledger networks. A second exemplary system architectureutilizes a set of shared full nodes while not having every node be ashared node.

First Exemplary System Architecture: Co-Located “Local” Full Nodes and“Foreign” PV Nodes

In a first exemplary system architecture 500 depicted in FIG. 5A,payment verification (PV) nodes for other (i.e. foreign) co-ledgers areco-located at all, or a portion of, nodes in each distributed ledgernetwork of the multiple distributed ledger system. The co-located PVnodes are used to support cross-ledger payment verification.

To reduce the resources needed to implement the system, the PV nodes maybe non-full nodes. In an exemplary implementation, each PV node mayimplemented as a simplified payment verification (SPV) node.Furthermore, while a multiple distributed ledger system with fourco-ledgers is depicted in FIG. 5A, a multiple distributed ledger systemmay include any number of co-ledgers.

In the example shown in FIG. 5A, a first distributed ledger A ismaintained by a first distributed ledger network 100A, a seconddistributed ledger B is maintained by a second distributed ledgernetwork 100B, a third distributed ledger C is maintained by a thirddistributed ledger network 100C, and a fourth distributed ledger D ismaintained by a fourth distributed ledger network 100D. Each of thesedistributed ledger networks (100A, 100B, 100C and 100D) includes its ownnodes 102 with interconnections 104 therebetween, as described above inrelation to FIG. 1. In addition, in accordance with an embodiment of theinvention, there are further communicative interconnections 502 betweensome nodes 102 in the different consensus networks so as tocommunicatively interconnect the consensus networks (100A, 100B, 100Cand 100D).

However, merely communicatively interconnecting the distributed ledgernetworks of the co-ledgers is insufficient because inter-ledgertransaction submission and verification are also needed to supportcross-ledger transfers. For this reason, at least some of the nodes 102in each distributed ledger network may be configured to run both a“local” full node-stack for its own distributed ledger and a “foreign”PV node-stack for the co-ledgers with which it is to interact.

A full node-stack for a distributed ledger includes a set of softwareroutines or programs at a full node of the distributed ledger network.The set of software routines or programs performs tasks and/or functionsrelating to the distributed ledger, including, if applicable: convertingAPI (application program interface) requests to distributed ledgertransactions; managing user keys; signing transactions; notifying othersystems when transactions are committed; submitting transactions to thedistributed ledger; and providing proofs of inclusion for transactions.A PV node-stack for a distributed ledger includes a reduced set ofsoftware routines or programs at a client communicating with thedistributed ledger network. The reduced set of software routines orprograms performs tasks and/or functions including: providing proofs ofinclusion for transactions; and submitting transactions to thedistributed ledger.

In the example of FIG. 5A, at least some of the nodes 102 in the firstnetwork 100A have been configured to also run PV nodes (PV-B, PV-C andPV-D) for each of the second, third and fourth networks (100B, 100C and100D). Similarly, at least some of the nodes 102 in the second network100B have been configured to also run PV nodes (PV-A, PV-C and PV-D) foreach of the first, third and fourth networks (100A, 100C and 100D).Also, at least some of the nodes 102 in the third network 100C have beenconfigured to also run PV nodes (PV-A, PV-B and PV-D) for each of thefirst, second and fourth networks (100A, 100B and 100D). Finally, atleast some of the nodes 102 in the fourth network 100D have beenconfigured to also run PV nodes (PV-A, PV-B and PV-C) for each of thefirst, second and third networks (100A, 100B and 100C).

Each PV-A node maintains a chain of block headers and signatures (i.e. ablock header/signature chain) for co-ledger A. Similarly, each PV-B nodemaintains a block header/signature chain for co-ledger B, each PV-C nodemaintains a block header/signature chain for co-ledger C, and each PV-Dnode maintains a block header/signature chain for co-ledger D.

FIG. 5B depicts an exemplary implementation of a computer system 510 fora node 102A in a distributed ledger network 100A within the systemarchitecture of FIG. 5A in accordance with an embodiment of theinvention. The computer system 510 may be implemented using multipleprocessors, including one or more central processing units (CPUs) andone or more graphics processing units (GPUs), for example.

As shown, the computer system 510 includes a full node-stack A 512-A forthe local distributed ledger A. The full node-stack A 512-A includes acomplete copy of the local distributed ledger A.

In addition, the computer system 510 includes a SPV node-stack B 514-Bfor the foreign distributed ledger B, a SPV node-stack C 514-C for theforeign distributed ledger C, and a SPV node-stack D 514-D for theforeign distributed ledger D. The SPV node-stack B 514-B includes ablock header/signature chain for the foreign distributed ledger B. TheSPV node-stack C 514-C includes a block header/signature chain for theforeign distributed ledger C. The SPV node-stack D 514-D includes ablock header/signature chain for the foreign distributed ledger D.

The structure of a block header/signature chain that may be maintainedat a PV node, particularly a PV node implemented as an SPV node, isdepicted in FIG. 5C. As shown in FIG. 5C, the block header/signaturechain 520 includes the block headers 522 and the block signatures 524 ofthe relevant distributed ledger, where the block signature is asignature by a block validator of the relevant distributed ledgernetwork which indicates that the validator accepts that the block thatis signed is valid.

Now consider that the first exemplary multiple distributed ledger system500, described above in relation to FIG. 5A, is to be constructed so asto achieve a goal of 100,000 transactions per second, for example, andthat each co-ledger is capable of individually handling 333 transactionsper second. To achieve 100,000 transactions per second, the multipledistributed ledger system 500 of FIG. 5A needs to have on the order of100,0000/333=300 co-ledgers. If there are 300 co-ledgers, then eachparticipant node must maintain SPV nodes for approximately 300 otherdistributed ledgers. (A participant node or validator in a distributedledger is a node that is allowed to vote on the validity of blocks. Asupermajority (for example, two-thirds or more) of the validators in thedistributed ledger generally must agree on the validity of the block forit to be committed to the chain.)

It may be estimated that each distributed ledger will produce about 7kilobytes of data per second to be maintained by an SPV node for thatledger. The data includes the block header and block signatures for thatdistributed ledger. This 7 kilobytes per second per co-ledger estimateassumes that we have no more than about 100 consensus participants foreach co-ledger, with a two-thirds (⅔) threshold of votes required, andthat there are 100 bytes per signature.

This results in about 300 distributed ledgers×7kilobytes/second/ledger=2,100 kilobytes/second of additional committedstorage to co-locate a “foreign” SPV node at each participating “local”full node. This estimated additional storage requirement is about twotimes the storage requirement without co-locating foreign SPV nodes.

In addition to this additional storage requirement, an index of blockhashes to block headers in the block header/signature chain may beprovided with the SPV node. The index may be used for the Merkle treereferencing depicted in FIG. 4 so as to perform inter-ledgerverification.

As the additional storage requirement for the PV nodes is manageable,the “foreign” PV nodes for all the other co-ledgers may be co-located atsome, or all of, the participating “local” nodes of a co-ledger.Furthermore, using the index provided with each PV node, theparticipating node may efficiently find the pertinent Merkle root so asto readily verify a transaction reference.

Second Exemplary System Architecture: Set of Shared Nodes

In a second exemplary system architecture 600 depicted in FIG. 6A, a setof nodes are shared by all the distributed ledger networks in themultiple distributed ledger system. Each of these shared nodes mayoperate as a full node for all the co-ledgers of the multipledistributed ledger system so as to efficiently support cross-ledgertransfers. Note that, while a multiple distributed ledger system withthree co-ledgers is depicted in FIG. 6A, any number of co-ledgers may beincluded in the system.

In the example shown in FIG. 6A, a first distributed ledger A ismaintained by a first distributed ledger network 100A, a seconddistributed ledger B is maintained by a second distributed ledgernetwork 100B, and a third distributed ledger C is maintained by a thirddistributed ledger network 100C. Each of these distributed ledgernetworks (100A, 100B, and 100C) includes nodes 102 with interconnections104 therebetween, as described above in relation to FIG. 1.

In accordance with an embodiment of the invention, there is a shared setof full nodes (100ABC). Each node in the shared set 100ABC isoperational as a full node of each of the three distributed ledgernetworks (100A, 100B, and 100C). As such, each node in the shared set100ABC contains a copy of each of the three distributed ledgers (A, Band C). Note that the three distributed ledgers (A, B, C) remainseparate distributed ledgers, each recording a separate ledger oftransactions.

In accordance with an embodiment of the invention, an index of blockhashes to block headers for each distributed ledger in the system may becreated from the distributed ledger data and provided at each node inthe shared set of full nodes (100ABC). The index may be used for theMerkle tree referencing depicted in FIG. 4 (from locking transaction 406to initiating transaction 404, and from completing transaction 408 tolocking transaction 406) so as to perform inter-ledger verification.

Any participant node may send a query through the network to a node ofthe shared set of full nodes (100ABC) to verify cross-ledgertransactions. This implies a trust in a central entity or other trustedentry to guarantee or certify that the provided full nodes for theco-ledgers are not lying about the contents of the co-ledgers.

FIG. 6B depicts an exemplary implementation of a computer system 610 fora node 102ABC in the set of shared nodes 100ABC within the systemarchitecture of FIG. 6A in accordance with an embodiment of theinvention. As shown, the computer system 610 includes a full node-stackA 512-A for the local distributed ledger A, a full node-stack B 512-Bfor the local distributed ledger B, and a full node-stack C 512-C forthe local distributed ledger C. The full node-stack A 512-A includes acomplete copy of the local distributed ledger A. The full node-stack B512-B includes a complete copy of the local distributed ledger B. Thefull node-stack C 512-C includes a complete copy of the localdistributed ledger C.

Flowchart of an Exemplary Cross-ledger Transfer

FIG. 7 is a flow chart of a method 700 for an owner of adigitally-represented economic value on a source distributed ledger totransfer the digitally-represented economic value to an entity on atarget distributed ledger in accordance with an embodiment of thepresent invention. In the particular example depicted, the value to betransferred is one million US dollars (USD).

Components used by the method 700 may include the following: a sourcedistributed ledger L_A; a target distributed ledger L_B; a first networknode that has a full node-stack (N_A) of L_A and which is alsoconfigured to operate as at least an SPV node (S_B) of L_B (and soincludes at least the block headers for L_B); and a second network nodethat has a full node-stack (N_B) of L_B and which is also configured tooperate as at least an SPV node (S_A) of L_A (and so includes at leastthe block headers for L_A).

The node-stack N_A may have the following data and capabilities: anindex of UTXOs on the assets of each entity using L_A; capability toconstruct transactions with those UTXOs; capability to listen forcommitted transactions from L_A; capability to submit transactions to aforeign node-stack (for example, N_B) to be committed to the foreigndistributed ledger (for example, L_B); capability to listen forcommitted transactions from a foreign node-stack (for example, N_B),where the transactions were submitted by itself; capabilities to acceptand index transactions submitted by a foreign node-stack (for example,N_B); and capability to push out committed transactions from L_A to aforeign node-stack (for example, N_B), if the committed transaction wassubmitted by itself.

Similarly, the node-stack N_B may have the following data andcapabilities: an index of UTXOs on the assets of each entity using L_B;capability to construct transactions with those UTXOs; capability tolisten for committed transactions from L_B; capability to submittransactions to a foreign node-stack (for example, N_A) to be committedto the foreign distributed ledger (for example, L_A); capability tolisten for committed transactions from a foreign node-stack (forexample, N_A), where the transactions were submitted by itself;capabilities to accept and index transactions submitted by a foreignnode-stack (for example, N_A); and capability to push out committedtransactions from L_A to a foreign node-stack (for example, N_A), if thecommitted transaction was submitted by itself.

Per step 1, as a client of node-stack N_A, entity A which is the assetowner and transfer source initiates a cross-ledger transfer of thespecified value (in this example, one million USD) from the sourcedistributed ledger A (L_A) to entity B on the target distributed ledgerB (L_B). Pseudo code relating to step 1 to be implemented in a fullnode-stack (for example, in node-stack N_A) is provided in lines 1-2 ofFIG. 9.

Per step 2, node-stack N_A identifies the specified value of entity A'sassets in UTXO U_1 in L_A. Pseudo code relating to step 2 to beimplemented in a full node-stack (for example, in node-stack N_A) isprovided in lines 3-4 of FIG. 9.

Per step 3, N_A builds the initiating transaction T_I of the specifiedvalue. Pseudo code relating to step 3 to be implemented in a fullnode-stack (for example, in node-stack N_A) is provided in lines 5-6 ofFIG. 9.

Per step 4, N_A submits T_I to node-stack N_B. Pseudo code relating tostep 4 to be implemented in a full node-stack (for example, innode-stack N_A) is provided in lines 11-14 of FIG. 9 which calls thepseudo code routine in FIG. 11.

Per step 5, node-stack N_B submits T_I to L_B. Pseudo code relating tostep 5 to be implemented in a full node-stack (for example, innode-stack N_B) is provided in lines 5-6 of FIG. 11 which calls thepseudo code routine in FIG. 12.

Per step 6, L_B commits T_I and notifies N_B once T_I has beencommitted. Step 6 may be performed using conventional code for thedistributed ledger.

After T_I has been committed to L_B, then, per step 7 a, SPV node S_Breceives the SPV information (i.e. the header and signatures) for theblock containing T_I. In addition, per step 7 b, N_B notifies N_A thatT_I was committed. Pseudo code relating to steps 7 a and 7 b to beimplemented in a full node-stack (for example, in node-stack N_B) isprovided by the pseudo code in FIGS. 13 and 14.

Per step 8, N_A constructs the locking transaction T_L which referencesT_I and locks U_1. Pseudo code relating to step 8 to be implemented in afull node-stack (for example, in node-stack N_A) is provided in lines7-12 of FIG. 10.

Per step 9, N_A submits T_L to L_A. Pseudo code relating to step 9 to beimplemented in a full node-stack (for example, in node-stack N_A ofdistributed ledger L_A) is in lines 13-14 of FIG. 10 which calls thepseudo code routine in FIG. 12.

Per step 10, L_A checks with S_B to verify that T_I (which is referencedin T_L) was committed by L_B. Pseudo code relating to step 10 to beimplemented by a distributed ledger (for example, distributed ledgerL_A) is provided in FIG. 12. An exemplary procedure for verifying that atransaction is committed in a foreign distributed ledger is describedbelow in relation to FIG. 8.

Per step 11, after successful verification, L_A commits T_L and notifiesN_A once T_L is committed. Step 11 may be performed using conventionalcode for the distributed ledger.

After T_L has been committed to L_A, then, per step 12 a, SPV node S_Areceives the SPV information (i.e. the header and signatures) for theblock containing T_L. In addition, per step 12 b, N_A constructs thecompleting transaction T_C which references T_L and has an output of thespecified value to be owned by the transfer target B. Pseudo coderelating to steps 12 a and 12 b to be implemented in a full node-stack(for example, in node-stack N_A) is provided by the pseudo code in FIGS.13 and 14.

Per step 13, N_A submits T_C to N_B. Pseudo code relating to step 13 tobe implemented in a full node-stack (for example, in node-stack N_A) isprovided in lines 27-30 of FIG. 10 and the pseudo code in FIG. 11.

Per step 14, N_B submits T_C to L_B. Pseudo code relating to step 14 tobe implemented in a full node-stack (for example, in node-stack N_A ofdistributed ledger L_A) is provided by the pseudo code in FIG. 12.

Per step 15, L_B checks with S_A to verify that T_L (which is referencedin T_C) was committed by L_A, and L_B also checks to verify that theinput to T_C is the output of T_I (which is referenced in T_L). Pseudocode relating to step 10 to be implemented by a distributed ledger (forexample, distributed ledger L_B) is provided in FIG. 12. An exemplaryprocedure for verifying that a transaction is committed in a foreigndistributed ledger is described below in relation to FIG. 8.

Per step 16, after the successful verifications, L_B commits T_C andnotifies N_B once T_C is committed. Step 16 may be performed usingconventional code for the distributed ledger.

Per step 17, N_B notifies N_A that T_C was committed by L_B. Pseudo coderelating to step 17 to be implemented in a full node-stack (for example,in node-stack N_B) is provided in FIG. 14.

Lastly, per step 18, N_B indexes the output of T_C for entity B. Pseudocode relating to step 18 to be implemented in a full node-stack (forexample, in node-stack N_B) is provided in lines 33-34 of FIG. 10.

Note that the method 700 described above is particularly suited for usewith the first system architecture 500 depicted in FIG. 5A. This isbecause the first system architecture 500 co-locates SPV nodes of aforeign distributed ledger with full nodes of a local distributedledger.

The method 700 may be readily modified for use with the second systemarchitecture 600 depicted in FIG. 6. The second system architecture 600co-locates full nodes of a foreign distributed ledger with full nodes ofa local distributed ledger. As such, steps 7 a and 12 a of the method700 are not needed. Furthermore, L_A may check with N_B to verify thatT_I was committed in step 10, and L_B may check with N_A to verify thatT_C was committed in step 15.

Inter-Ledger Transaction Verification

In order to verify transaction references in foreign distributedledgers, it is necessary to have a trustworthy verification mechanismfor what is being committed into these other distributed ledgers. Such amechanism for verifying a transaction in another distributed ledger isnot provided by conventional distributed ledger technology.

An exemplary process 800 for verifying transactions in a foreigndistributed ledger is shown in FIG. 8. The process 800 may be applied,for example, in step 10 of FIG. 7 to verify that the initiatingtransaction exists in the target distributed ledger, and in step 15 ofFIG. 7 to verify that the locking transaction exists in the sourcedistributed ledger.

Per step 801, the reference data of the transaction input for thetransaction being verified is passed inside a query from the local nodeto one or more foreign nodes. The local node is a node of the localdistributed ledger, and a foreign node is a node of the foreigndistributed ledger in which the transaction is to be verified.

802) The foreign node(s) use the ledger identifier (for example, chainid) in the transaction input to find the correct index to query, thecorrect index being that associated with the ledger identifier. Theinput to the index is a block hash for the block that contains thetransaction being verified.

803) The foreign node(s) use the block hash in the transaction input tofind the correct block to examine.

804) The foreign node(s) extract the block header from the identifiedblock (that was found in step 803).

805) The foreign node(s) extract the Merkle root hash from theidentified block. 806) The foreign node(s) compute a transaction hashfor the transaction in the transaction input.

807) The foreign node(s) compute a Merkle root hash from the transactionhash and the provided Merkle branch hashes.

808) The foreign node(s) compare the computed Merkle root hash with theMerkle root hash in the identified block.

809) The foreign node(s) returns to the local node that the transactionis valid if the hashes match, invalid if they don't match.

Note that, if multiple foreign nodes are queried in the above-describedverification method 800, then the transaction may be considered asvalidly committed as long as one of the foreign nodes returns that thetransaction is valid.

Note also that the method 800 described above may be used in either thefirst system architecture 500 depicted in FIG. 5A or the second systemarchitecture 600 depicted in FIG. 6. For the first system architecture500, a foreign node may correspond to a foreign SPV node-stack which isco-located with a local full node-stack. For the second systemarchitecture 600, a foreign node-stack may be a foreign full node-stackwhich is co-located with a local full node-stack.

FIGS. 9 through 14 show pseudocode that provides a detailed “blueprint”for an exemplary implementation of an embodiment of the presentinvention. Comments in the pseudocode are preceded by //.

Initiate Transaction

The pseudocode procedure shown in FIG. 9 is performed when across-ledger transaction is submitted to a node stack. In order toconstruct the transaction, a UTXO must be found corresponding to theasset that is to be transacted. Once that UTXO is found, an initiatingtransaction should be constructed out of that UTXO. This initiatingtransaction should be indexed for later lookup, along with the source ofthe transaction and the target of the transaction. The initiatingtransaction should be signed by the owner of the asset in the UTXO.Then, the target node stack is located, and the initiating transactionis sent to the target node stack, along with knowledge of the source.

Notify Committed Transaction

The pseudocode procedure shown in FIG. 10 is performed when a node stackis notified that a transaction has been committed. There are two cases,depending on whether the transaction is an initiating transaction or alocking transaction.

The first case is if the transaction that is committed is an initiatingtransaction. When this occurs, we can look up the UTXO that we need tolock from the index described in FIG. 9. We then build a lockingtransaction out of this UTXO. This transaction needs to be signed by theowner of the asset in the UTXO, which we also look up using the indexdescribed in FIG. 9. Finally, we submit this transaction to the localledger.

The second case is if the transaction that is committed is a lockingtransaction. When this occurs, we first find the target for theinitiating transaction referenced by the locking transaction. This isavailable from the index described in FIG. 9. We build a completingtransaction that references the locking transaction. This completingtransaction requires the signature of the owner of the asset beingtransferred; this can be looked up in the index described in FIG. 9.Finally, we find the node stack for the target, and the completingtransaction is sent to the target node stack, along with knowledge ofthe source.

For all transactions that the node stack is notified of, the availableUTXO pool needs to be updated.

Commit Foreign Transaction

The pseudocode procedure shown in FIG. 11 is performed when a node stackreceives a transaction from a foreign node stack (such as when aninitiating or completing transaction is received). The transaction isindexed to the source that the transaction is received from, then thetransaction is submitted to the local distributed ledger.

Submit Transaction to Ledger

The pseudocode procedure shown in FIG. 12 is performed when adistributed ledger receives a submitted transaction. There are somesteps that are taken to perform common validations across alltransactions, that are skipped (not shown) in the figure. For thosetransactions that contain SPV references (the locking and completingtransactions), we apply certain validations to their inputs.

If we find that an input contains an SPV reference (in the case of thelocking and completing transactions), we verify that the SPV referenceis valid, by calling a verification API on the SPV node. Furthermore, ifwe find that an input contains an SPV reference that contains atransaction with an SPV reference (as in the case of a completingtransaction), we check if the contained transaction's SPV referencetransaction ID matches the initiating transaction that the completingtransaction spends. If all validations are passed, the transaction isready to be committed by the ledger.

Commit Block to Ledger

The pseudocode procedure shown in FIG. 13 is performed when adistributed ledger commits a block containing transactions. The figuredoes not show the process where the distributed ledger decides how toadd transactions to blocks and how the ledgers reach consensus onblocks, as those topics are beyond the scope of this disclosure. In theprocedure shown, the ledger stores the block to some persisted storage,sends SPV info for the block to the SPV node, then notifies the localnode stack that the block has been committed.

Send Messages for Committed Transactions

The pseudocode procedure of FIG. 14 shows how a local node stackdistributes notifications regarding committed transactions. Thisprocedure is performed for the initiating and completing transactions.

For all transactions in a block, the local node stack looks in theforeign index (defined in FIG. 11) to determine whether the transactionhad a foreign source. If the transaction had a foreign source, the localnode stack finds the node stack for the foreign source and sends thecommitted transaction and SPV information for the committed transactionover to that foreign node stack. The local node stack is notified of allcommitted transactions (whether the source is local or foreign).

Transaction Structures

FIG. 15 shows a general structure for a standard transaction 1500 whichmay include a cross-ledger referenced transaction input accordance withan embodiment of the present invention. The standard transaction in FIG.15 includes a list of transaction inputs and a list of transactionoutputs.

In this case, there are two types of transaction inputs. A first type oftransaction input is an intra-ledger (i.e. standard) transaction input1502. Each intra-ledger transaction input includes bytes which identifythe input transaction and an integer which provides the output offsetfor the input transaction.

A second type of transaction input is a cross-ledger referencedtransaction input 1504. Each cross-ledger referenced transaction inputincludes bytes which identify the foreign ledger, bytes for a block hashwhich identifies the block within the foreign ledger, a list of Merklebranch hashes for the transactions in the identified block, transactionbytes of the input transaction within the identified block, and aninteger offset which provides the offset for a specific output beingreferenced within the given transaction bytes.

Each transaction output 1506 includes bytes which identify the digitalproperty being output and a bytes lock which is an encoded lock for thetransaction output. The bytes lock is unlocked by providing a signaturefrom the matching private key.

FIGS. 16 through 18 show structures for the three transactions whichtogether provide a cross-ledger transfer in accordance with anembodiment of the present invention. These three structures may be usedto implement the three-transaction cross-ledger transfer 400 depicted inFIG. 4.

FIG. 16 shows a specific structure for an initiating transaction 1600 ofthe three-transaction cross-ledger transfer in accordance with anembodiment of the present invention. The initiating transaction includesno transaction inputs and a single transaction output 1606.

The transaction output 1606 includes bytes that identify the digitalproperty being transferred and a byte lock. The byte lock may beunlocked (for spending the digital property) only by a completingtransaction with a reference to a locking transaction which referencesthis initiating transaction.

FIG. 17 shows a specific structure for a locking transaction 1700 of thethree-transaction cross-ledger transfer in accordance with an embodimentof the present invention. The locking transaction 1700 includes a listof transaction inputs and a list of transaction outputs.

The transaction inputs include one or more intra-ledger transactioninput 1702 and a single cross-ledger reference transaction input 1704.

Each intra-ledger transaction input 1702 includes bytes which identifyan input transaction in the source ledger and an integer which providesthe output offset for that transaction. Each input transactioncorresponds to an existing transaction in the source ledger, and theoutput offset indicates a specific output of the existing transactionthat is being input to the locking transaction 1700.

The cross-ledger reference transaction input 1704 is used to referencethe initiating transaction in the target ledger. The cross-ledgerreference transaction input 1704 includes bytes which identify thetarget ledger, bytes for a block hash which identifies the block withinthe target ledger, a list of Merkle branch hashes for the transactionsin the identified block, transaction bytes of the initiating transactionwithin the identified block, and an integer offset which provides theoffset for a specific output being referenced within the giventransaction bytes.

The locking transaction 1700 does not need any transaction output 1706and so may have zero or more transaction outputs 1706. If there is atransaction output 1706, it includes bytes that identify the digitalproperty being output and a byte lock. The digital property of thetransaction outputs 1706 must be equal to the difference between thedigital property that the intra-ledger transaction inputs 1702 point to(from the output or outputs of one or more existing transactions) andthe digital property that the cross-ledger reference transaction input1704 points to (from the specified output of the initiatingtransaction). If those amounts of digital property are equal, then thereis no transaction output 1706.

FIG. 18 shows a specific structure for a completing transaction 1800 ofthe three-transaction cross-ledger transfer in accordance with anembodiment of the present invention. The completing transaction 1800includes two transaction inputs and one or more transaction outputs.

The two transaction inputs include a single intra-ledger transactioninput 1802 and a single cross-ledger reference transaction input 1804.

The intra-ledger transaction input 1802 includes bytes of a transactionID which identifies the initiating transaction in the target ledger andan integer which provides the output offset for that transaction. Theoutput offset indicates a specific output of the initiating transactionthat is being input to the completing transaction 1800. This transactionID in the intra-ledger transaction input 1802 must match the transactionID of the initiating transaction pointed at by the locking transaction;otherwise, the completing transaction will be invalid.

The cross-ledger reference transaction input 1804 is used to referencethe locking transaction in the source ledger. The cross-ledger referencetransaction input 1804 includes bytes which identify the source ledger,bytes for a block hash which identifies the block within the sourceledger, a list of Merkle branch hashes for the transactions in theidentified block, transaction bytes of the locking transaction withinthe identified block, and an integer offset which provides the offsetfor a specific output being referenced within the given transactionbytes, if any.

There may be one or more transaction outputs 1806. Each transactionoutput 1806 includes bytes which identify the digital property beingoutput and a bytes lock which is an encoded lock for the transactionoutput. The bytes lock is unlocked by providing a signature from thematching private key.

System Performance Calculations Showing Scalability Gains

This section describes scalability gains as evidenced by calculations ofsystem performance for a system having multiple distributed ledgers (forexample, multiple blockchains).

The variable definitions for the calculations are as follows:

-   -   R=the number of remittances per second per ledger;    -   X=the number of intra-ledger transactions per second per ledger;    -   Y=the number of inter-ledger transactions per second per ledger;        and    -   N=the number of co-ledgers in the system.

The assumptions for the calculations are as follows:

-   -   1) A worst-case distribution of transactions across the N        distributed ledgers is assumed such that ratio of intra-ledger        transactions to inter-ledger transactions of 1 to N−1;    -   2) Blocks are one megabyte (1 MB) in size;    -   3) The processing rate for blocks of a distributed ledger is 1        block per second;    -   4) Intra-ledger transactions take about 1000 bytes=1 kilobyte;    -   5) The worst-case size of a transaction reference is        log₂(3000)*32 bytes+32 bytes=416 bytes; and    -   6) Inter-ledger transactions to transfer digitally-represented        economic value each constitutes 5 transactions and take 2814        bytes in total due to the following steps:        -   a) Subscriber send transaction takes about 333 bytes;        -   b) Initiating transaction takes about 200 bytes;        -   c) Locking transaction takes size of initiating+416            bytes+100 bytes=716 bytes;        -   d) Completing transaction takes size of locking+416            bytes+100 bytes=1232 bytes; and        -   e) Subscriber receive transaction takes about 333 bytes.

Based on the above definitions and assumptions, the followingcalculations are made:

X/Y=1/(N−1) by the ratio of intra-ledger to inter-ledger transactionsbeing 1/(N−1).

10⁶=1000X+2814Y by the block size of 1 MB and the size of the two typesof transactions being 1000 bytes and 2814 bytes.

R=X+Y because the remittances per second per ledger is the sum of theintra-ledger transactions per second per ledger and the inter-ledgertransactions per second per ledger.

Solving for R as a function of N gives R=10⁶ N/(2814N−1814).

If we target N*R=10⁵ remittances per second (RPS) in aggregate for thesystem, then we obtain the following quadratic equation.

N ²−281.4N+181.4=0

Solving for the roots of the above equation and taking the result thatmust be greater than one for practical reasons gives the number ofco-ledgers N=281. This result means that, given the assumptions above,281 co-ledgers must be run which each commit 1 MB per second in order tohave an aggregate transaction throughput of 10⁵ RPS for the system.

The calculated transaction throughput per co-ledger in RPS as a functionof the number of co-ledgers, N, in the system is shown by the graph inFIG. 19 in accordance with an embodiment of the present invention. Thetotal transaction throughput in RPS is equal to the RPS per ledgermultiplied by the number of co-ledgers, N. As seen in the graph, atN=281, the RPS per ledger (per co-chain when each ledger is ablockchain) is 356 such that the system throughput is about 10⁵.

The calculated aggregate transaction throughput for the system in RPS asa function of the number of co-ledgers (co-chains when each ledger is ablockchain) is shown by the graph in FIG. 20 in accordance with anembodiment of the present invention. As shown, the aggregate transactionthroughput scales linearly with the number of co-ledgers in the system.

Note that the calculations presented above are based on a worst-casedistribution of transactions in the system and a worst-case size of atransaction reference. It is very likely that, at least in many cases,the assignment of nodes to the various consensus networks in the systemmay be made so as to greatly increase the ratio X/Y of intra-ledgertransactions to inter-ledger transactions to be greater than one. Inother words, a system is likely to be configurable such that there aremore intra-ledger transactions than inter-ledger transactions. Incontrast, the worst-case assumption in the above-described calculationsis that there are many more inter-ledger transactions than intra-ledgertransactions. Hence, the performance of an actual system is potentiallymuch better than the system performance in the above calculations.

Computer System

FIG. 21 depicts, at a high level, components of a computer system 2100that may be used, for example, to implement full or partial nodes of adistributed ledger network. A computer system may be implemented withfewer or more components than shown in the figure. For example, thecomputer systems may include one or more processors 2101 (includinggraphics processors) and one or more buses 2103 coupling its variouscomponents. The computer system may also include one or more user inputdevices 2102 (e.g., keyboard, mouse), one or more data storage devices2106 (e.g., hard drives, optical disks, solid state memory disks), oneor more display monitors 2104 (e.g., liquid crystal display, flat panelmonitor), one or more computer network interfaces 2105 (e.g., networkadapter, modem), and a main memory 2108 (i.e., random access memory). Asshown, a computer network interface 2105 may be coupled to a computernetwork 2109, which may be, in this case, a distributed ledger network.

The computer system is a particular machine as programmed with one ormore software modules, comprising computer-readable code or instructionsstored in a non-transitory manner in the main memory 2108 for executionby the processor 2101. An article of manufacture may be embodied ascomputer-readable storage medium including instructions that whenexecuted by a processor 2101 causes the computer system to be operableto perform the functions of the one or more software modules.

Exemplary Embodiments

Exemplary embodiments of the presently-disclosed invention include, butare not limited to, the following.

-   Embodiment A1. A method of spending a digitally-represented economic    value in a target distributed ledger where the digitally-represented    economic value originates in a source distributed ledger and is    owned by an entity, the method comprising:

determining an existing transaction in the source distributed ledgerwhich has a transaction output that is unspent and owned by the entity;

constructing and submitting an initiating transaction for commission tothe target distributed ledger, wherein the initiating transaction has atransaction output;

constructing and submitting a locking transaction for commission to thesource distributed ledger, wherein the locking transaction spends andlocks the transaction output of the existing transaction in the sourcedistributed ledger and references the initiating transaction in thetarget distributed ledger; and

constructing and submitting a completing transaction for commission tothe target distributed ledger, wherein the completing transaction spendsthe transaction output of the initiating transaction in the targetdistributed ledger and references the locking transaction in the sourcedistributed ledger.

-   Embodiment A2. The method of Embodiment A1, wherein the transaction    output of the initiating transaction is only spendable by the    completing transaction when the completing transaction references    the locking transaction and when a value of the transaction output    of the initiating transaction matches a value of the transaction    output of the existing transaction.-   Embodiment A3. The method of Embodiment A2, wherein the locking    transaction uses a Merkle tree reference to reference the initiating    transaction.-   Embodiment A4. The method of Embodiment A3, wherein the completing    transaction uses a Merkle tree reference to reference the locking    transaction.-   Embodiment A5. The method of Embodiment A1, wherein the method is    performed by a node-stack of the source distributed ledger.-   Embodiment A6. The method of Embodiment A5, wherein the initiating    and completing transactions are submitted to a node-stack of the    target distributed ledger, and the node-stack of the target    distributed ledger further submits the initiating and completing    transactions to the target distributed ledger.-   Embodiment A7. The method of Embodiment A1, wherein the method is    performed by a node-stack of the target distributed ledger.-   Embodiment A8. The method of Embodiment A7, wherein the locking    transaction is submitted to a node-stack of the source distributed    ledger, and the node-stack of the source distributed ledger further    submits the locking transaction to the source distributed ledger.-   Embodiment A9. The method of Embodiment A1, wherein the method is    performed in a system that comprises:

a plurality of distributed ledger networks, each said distributed ledgernetwork having a plurality of nodes and communicative connectionstherebetween; and

internetwork connections between the plurality of distributed ledgernetworks,

wherein a distributed ledger network that maintains a local distributedledger includes a plurality of foreign payment verification nodes forother distributed ledgers in the system.

-   Embodiment A10. The method of Embodiment A1, wherein the method is    performed in a system that comprises:

a plurality of distributed ledger networks, each said distributed ledgernetwork having a plurality of nodes and internetwork connectionstherebetween; and

a set of nodes that are shared by the plurality of distributed ledgernetworks, wherein nodes in the set provide, among other services,inter-ledger verification of transactions.

-   Embodiment A11. A non-transitory tangible computer-readable medium    comprising instructions stored thereon, that when executed by a    processor, perform the steps of:

determining an existing transaction in a source distributed ledger whichhas a transaction output that is unspent and owned by an entity;

constructing and submitting an initiating transaction for commission toa target distributed ledger, wherein the initiating transaction has atransaction output;

constructing and submitting a locking transaction for commission to thesource distributed ledger, wherein the locking transaction spends andlocks the transaction output of the existing transaction in the sourcedistributed ledger and references the initiating transaction in thetarget distributed ledger; and

constructing and submitting a completing transaction for commission tothe target distributed ledger, wherein the completing transaction spendsthe transaction output of the initiating transaction in the targetdistributed ledger and references the locking transaction in the sourcedistributed ledger.

-   Embodiment A12. The computer-readable medium of claim Embodiment    A11, wherein the transaction output of the initiating transaction is    only spendable by the completing transaction when the completing    transaction references the locking transaction and when a value of    the transaction output of the initiating transaction matches a value    of the transaction output of the existing transaction.-   Embodiment A13. The computer-readable medium of claim Embodiment    A12, wherein the locking transaction uses a Merkle tree reference to    reference the initiating transaction.-   Embodiment A14. The computer-readable medium of claim Embodiment    A13, wherein the completing transaction uses a Merkle tree reference    to reference the locking transaction.-   Embodiment A15. The computer-readable medium of claim Embodiment    A11, wherein the instructions are performed by a node-stack of the    source distributed ledger.-   Embodiment A16. The computer-readable medium of claim Embodiment    A11, wherein the instructions are performed by a node-stack of the    target distributed ledger.-   Embodiment A17. A method of transferring a digitally-represented    amount of currency in an unspent transaction output of an existing    transaction in a source blockchain to one or more transaction    outputs which spend the digitally-represented amount of currency in    a target blockchain, the method comprising:

constructing and submitting an initiating transaction for commission tothe target blockchain, wherein the initiating transaction has theunspent transaction output which comprises the digitally-representedamount of currency;

constructing and submitting a locking transaction for commission to thesource blockchain, wherein the locking transaction spends and locks thetransaction output of the existing transaction in the source blockchainand references the initiating transaction in the target blockchain; and

constructing and submitting a completing transaction for commission tothe target blockchain, wherein the completing transaction references thelocking transaction in the source blockchain, and wherein the completingtransaction comprises said one or more transaction outputs which spendthe digitally-represented amount of currency in the target blockchain.

-   Embodiment A18. The method of Embodiment A17, wherein the    transaction output of the initiating transaction is only spendable    by the completing transaction when the completing transaction    references the locking transaction and when a value of the    transaction output of the initiating transaction matches a value of    the transaction output of the existing transaction-   Embodiment A19. The method of Embodiment A18, wherein the locking    transaction uses a Merkle tree reference to reference the initiating    transaction.-   Embodiment A20. The method of Embodiment A19, wherein the completing    transaction uses a Merkle tree reference to reference the locking    transaction.-   Embodiment A21. The method of Embodiment A1, wherein the distributed    ledger comprises a blockchain.-   Embodiment A22. The method of Embodiment A1, wherein the distributed    ledger utilizes a directed acyclic graph.-   Embodiment A23. The computer-readable medium of claim Embodiment    A11, wherein the distributed ledger comprises a blockchain.-   Embodiment A24. The computer-readable medium of claim Embodiment    A11, wherein the distributed ledger utilizes a directed acyclic    graph.-   Embodiment B1. A system with cross-ledger transfers between multiple    distributed ledgers for highly-scalable transaction throughput, the    system comprising:

a plurality of distributed ledger networks, each said distributed ledgernetwork maintaining a local distributed ledger and comprising localnodes and communicative connections therebetween;

internetwork connections between the plurality of distributed ledgernetworks; and

foreign payment verification nodes co-located with the local nodes ofeach said distributed ledger network, wherein the foreign paymentverification nodes are used in a cross-ledger transfer for inter-ledgerverification of transactions in other distributed ledger networks in thesystem.

-   Embodiment B2. The system of Embodiment B1, further comprising, at    each said foreign payment verification node:

a block header/signature chain that includes block headers and blocksignatures for a foreign distributed ledger.

-   Embodiment B3. The system of Embodiment B2, further comprising, at    each said payment verification node:

an index of block hashes to the block headers in the blockheader/signature chain.

-   Embodiment B4. The system of Embodiment B1, wherein an existing    transaction in a source distributed ledger contains a transaction    output whose digitally-represented economic value is to be    transferred to a target distributed ledger.-   Embodiment B5. The system of Embodiment B4, wherein inter-ledger    verification comprises verifying existence of a locking transaction    in the source distributed ledger, and wherein the locking    transaction spends the transaction output of the existing    transaction.-   Embodiment B6. The system of Embodiment B5, wherein verification of    the existence of the locking transaction in the source distributed    ledger is necessary for a completing transaction in the target    distributed ledger to spend a transaction output of an initiating    transaction in the target distributed ledger.-   Embodiment B7. The system of Embodiment B1, wherein said co-location    of the local node and the foreign payment verification nodes is    implemented by a computer apparatus with one or more processors that    includes a local node-stack of the local distributed ledger and    foreign payment verification node-stacks of the other distributed    ledgers in the system.-   Embodiment B8. A system with cross-ledger transfers between a    plurality of distributed ledgers for highly-scalable transaction    throughput, the system comprising:

a plurality of distributed ledger networks, each said distributed ledgernetwork maintaining a local distributed ledger and comprising localnodes and communicative connections therebetween; and

a set of shared nodes, wherein each said shared node comprises localnodes for at least two distributed ledger networks of the plurality ofdistributed ledger networks.

-   Embodiment B9. The system of Embodiment B8, further comprising, at    each said shared node:

an index of block hashes to block headers for each of the plurality ofdistributed ledgers.

-   Embodiment B10. The system of Embodiment B8, wherein each said    shared node comprises a computer apparatus which comprises local    node-stacks of said at least two distributed ledger networks.-   Embodiment B11. The system of Embodiment B8, wherein each said    shared node comprises local nodes for all of the plurality of    distributed ledger networks.-   Embodiment B12. The system of Embodiment B11, wherein each said    shared node comprises a computer apparatus which comprises local    node-stacks of all of the plurality of distributed ledger networks.-   Embodiment B13. The system of Embodiment B8, wherein an existing    transaction in a source distributed ledger contains a transaction    output whose digitally-represented economic value is to be    transferred to a target distributed ledger.-   Embodiment B14. The system of Embodiment B13, wherein a locking    transaction spends the transaction output of the existing    transaction, and wherein verification of the existence of the    locking transaction in the source distributed ledger is necessary    for a completing transaction in the target distributed ledger to    spend a transaction output of an initiating transaction in the    target distributed ledger.-   Embodiment B15. A system with cross-ledger transfers between a    plurality of distributed ledgers for highly-scalable transaction    throughput, the system comprising:

a set of computer apparatus, each said computer apparatus comprisingmemory for holding computer-readable code and data and one or moreprocessors for executing said computer-readable code so as to modifysaid data;

communicative connections between each said computer apparatus and aplurality of distributed ledger networks; and

computer-readable code for local node-stacks of the plurality ofdistributed ledger networks at each said computer apparatus.

-   Embodiment B16. The system of Embodiment B15, further comprising, at    each said computer apparatus:

an index of block hashes to block headers for each of the plurality ofdistributed ledgers.

-   Embodiment B17. The system of Embodiment B15, wherein an existing    transaction in a source distributed ledger contains a transaction    output whose digitally-represented economic value is to be    transferred to a target distributed ledger.-   Embodiment B18. The system of Embodiment B17, wherein a locking    transaction spends the transaction output of the existing    transaction, and wherein verification of the existence of the    locking transaction in the source distributed ledger is necessary    for a completing transaction in the target distributed ledger to    spend a transaction output of an initiating transaction in the    target distributed ledger.-   Embodiment B19. The system of Embodiment B15, wherein the    distributed ledger comprises a blockchain.-   Embodiment B20. The system of Embodiment B15, wherein the    distributed ledger utilizes a directed acyclic graph.-   Embodiment B21. The system of Embodiment B1, wherein the distributed    ledger comprises a blockchain.-   Embodiment B22. The system of Embodiment B1, wherein the distributed    ledger utilizes a directed acyclic graph.-   Embodiment B23. The system of Embodiment B8, wherein the distributed    ledger comprises a blockchain.-   Embodiment B24. The system of Embodiment B8, wherein the distributed    ledger utilizes a directed acyclic graph.-   Embodiment C1. A computer apparatus for cross-ledger transfers    between a plurality of distributed ledgers, the computer apparatus    comprising:

memory for holding computer-readable code and data;

one or more processors for executing said computer-readable code so asto modify said data;

computer-readable code for a local node-stack for a target distributedledger of the plurality of distributed ledgers; and

computer-readable code for a foreign payment verification node-stack fora source distributed ledger of the plurality of distributed ledgers,

wherein the local node-stack is configured to use the foreign paymentverification node-stack to verify transactions in the source distributedledger during a cross-ledger transfer of a digitally-representedeconomic value between the target and source distributed ledgers.

-   Embodiment C2. The computer apparatus of Embodiment C1, further    comprising, at the foreign payment verification node-stack:

a block header/signature chain that includes block headers and blocksignatures for the source distributed ledger.

-   Embodiment C3. The computer apparatus of Embodiment C2, further    comprising, at the foreign payment verification node-stack:

an index of block hashes to the block headers in the blockheader/signature chain.

-   Embodiment C4. The computer apparatus of Embodiment C1, wherein an    existing transaction in the source distributed ledger contains a    transaction output which has the digitally-represented economic    value for the cross-ledger transfer.-   Embodiment C5. The computer apparatus of Embodiment C4, wherein the    local node-stack is configured to construct a locking transaction    which spends and locks the digitally-represented economic value of    the transaction output of the existing transaction such that the    digitally-represented economic value cannot be further spent in the    source distributed ledger.-   Embodiment C6. The computer apparatus of Embodiment C5, wherein the    locking transaction comprises at least one intra-ledger transaction    input, one cross-ledger reference transaction input, and zero or    more transaction outputs.-   Embodiment C7. The computer apparatus of Embodiment C5, wherein the    local node-stack is required, prior to constructing a completing    transaction which spends a transaction output of an initiating    transaction in the target distributed ledger, to verify existence of    the locking transaction in the source distributed ledger and match a    value of the transaction output of the initiating transaction    against the value spent by the locking transaction.-   Embodiment C8. The computer apparatus of Embodiment C7, wherein the    initiating transaction comprises no transaction inputs and one    transaction output.-   Embodiment C9. The computer apparatus of Embodiment C7, wherein the    completing transaction comprises one intra-ledger transaction input,    one cross-ledger reference transaction input, and one or more    transaction outputs.-   Embodiment C10. A computer apparatus for cross-ledger transfers    between a plurality of distributed ledgers, the computer apparatus    comprising:

memory for holding computer-readable code and data;

one or more processors for executing said computer-readable code so asto modify said data; and

computer-readable code for node-stacks of the plurality of distributedledgers,

wherein each said node-stack is configured to perform a cross-ledgertransfer of a digitally-represented economic value from a sourcedistributed ledger to a target distributed ledger.

-   Embodiment C11. The computer apparatus of Embodiment C10, further    comprising:

an index of block hashes to block headers for each of the plurality ofdistributed ledgers.

-   Embodiment C12. The computer apparatus of Embodiment C10, wherein an    existing transaction in the source distributed ledger contains a    transaction output whose digitally-represented economic value is to    be transferred to the target distributed ledger.-   Embodiment C13. The computer apparatus of Embodiment C12, wherein a    locking transaction spends and locks the transaction output of the    existing transaction.-   Embodiment C14. The computer apparatus of Embodiment C13, wherein    the locking transaction comprises at least one intra-ledger    transaction input, one cross-ledger reference transaction input, and    zero or more transaction outputs.-   Embodiment C15. The computer apparatus of Embodiment C13, wherein    verification of the existence of the locking transaction in the    source distributed ledger is necessary for a completing transaction    in the target distributed ledger to spend a transaction output of an    initiating transaction in the target distributed ledger.-   Embodiment C16. The computer apparatus of Embodiment C15, wherein    the initiating transaction comprises no transaction inputs and one    transaction output.-   Embodiment C17. The computer apparatus of Embodiment C15, wherein    the completing transaction comprises one intra-ledger transaction    input, one cross-ledger reference transaction input, and one or more    transaction outputs.-   Embodiment C18. An apparatus for cross-ledger transfers between a    plurality of distributed ledgers, the apparatus comprising:

means for determining an existing transaction in the source distributedledger which has a transaction output that is unspent and owned by theentity;

means for constructing and submitting an initiating transaction forcommission to the target distributed ledger, wherein the initiatingtransaction has a transaction output;

means for constructing and submitting a locking transaction forcommission to the source distributed ledger, wherein the lockingtransaction spends and locks the transaction output of the existingtransaction in the source distributed ledger and references theinitiating transaction in the target distributed ledger; and

means for constructing and submitting a completing transaction forcommission to the target distributed ledger, wherein the completingtransaction spends the transaction output of the initiating transactionin the target distributed ledger and references the locking transactionin the source distributed ledger.

-   Embodiment C19. The apparatus of Embodiment C18, wherein the    transaction output of the initiating transaction is only spendable    by the completing transaction when the completing transaction    references the locking transaction and when a value of the    transaction output of the initiating transaction matches a value of    the transaction output of the existing transaction.-   Embodiment C20. The apparatus of Embodiment C18, wherein the    distributed ledger comprises a blockchain.-   Embodiment C21. The apparatus of Embodiment C18, wherein the    distributed ledger utilizes a directed acyclic graph.-   Embodiment C22. The computer apparatus of Embodiment C1, wherein the    distributed ledger comprises a blockchain.-   Embodiment C23. The computer apparatus of Embodiment C1, wherein the    distributed ledger utilizes a directed acyclic graph.-   Embodiment C24. The computer apparatus of Embodiment C10, wherein    the distributed ledger comprises a blockchain.-   Embodiment C25. The computer apparatus of Embodiment C10, wherein    the distributed ledger utilizes a directed acyclic graph.

CONCLUSION

The presently-disclosed solution uses multiple distributed ledgers andcross-ledger transfers to achieve highly scalable transactionthroughput. Disclosed are methods and instruction code for writing across-ledger transfer in a way that effectively transfers value from asource to a target blockchain while preventing double spending of thevalue. Also disclosed are system architectures that utilize cross-ledgertransfers between multiple distributed ledgers to achievehighly-scalable transaction throughput. Also disclosed are computerapparatus configured to implement cross-ledger transfers betweendistributed ledgers.

In the present disclosure, numerous specific details are provided, suchas examples of systems, components, and methods, to provide a thoroughunderstanding of embodiments of the invention. Persons of ordinary skillin the art will recognize, however, that the invention can be practicedwithout one or more of the specific details. In other instances,well-known details are not shown or described to avoid obscuring aspectsof the invention.

While specific embodiments of the present invention have been provided,it is to be understood that these embodiments are for illustrationpurposes and not limiting. Many additional embodiments will be apparentto persons of ordinary skill in the art reading this disclosure.

What is claimed is:
 1. A system with cross-ledger transfers betweenmultiple distributed ledgers for highly-scalable transaction throughput,the system comprising: a plurality of distributed ledger networks, eachsaid distributed ledger network maintaining a local distributed ledgerand comprising local nodes and communicative connections therebetween;internetwork connections between the plurality of distributed ledgernetworks; and foreign payment verification nodes co-located with thelocal nodes of each said distributed ledger network, wherein the foreignpayment verification nodes are used in a cross-ledger transfer forinter-ledger verification of transactions in other distributed ledgernetworks in the system.
 2. The system of claim 1, further comprising, ateach said foreign payment verification node: a block header/signaturechain that includes block headers and block signatures for a foreigndistributed ledger.
 3. The system of claim 2, further comprising, ateach said payment verification node: an index of block hashes to theblock headers in the block header/signature chain.
 4. The system ofclaim 1, wherein an existing transaction in a source distributed ledgercontains a transaction output whose digitally-represented economic valueis to be transferred to a target distributed ledger.
 5. The system ofclaim 4, wherein inter-ledger verification comprises verifying existenceof a locking transaction in the source distributed ledger, and whereinthe locking transaction spends the transaction output of the existingtransaction.
 6. The system of claim 5, wherein verification of theexistence of the locking transaction in the source distributed ledger isnecessary for a completing transaction in the target distributed ledgerto spend a transaction output of an initiating transaction in the targetdistributed ledger.
 7. The system of claim 1, wherein said co-locationof the local node and the foreign payment verification nodes isimplemented by a computer apparatus with one or more processors thatincludes a local node-stack of the local distributed ledger and foreignpayment verification node-stacks of the other distributed ledgers in thesystem.
 8. A system with cross-ledger transfers between a plurality ofdistributed ledgers for highly-scalable transaction throughput, thesystem comprising: a plurality of distributed ledger networks, each saiddistributed ledger network maintaining a local distributed ledger andcomprising local nodes and communicative connections therebetween; and aset of shared nodes, wherein each said shared node comprises local nodesfor at least two distributed ledger networks of the plurality ofdistributed ledger networks.
 9. The system of claim 8, furthercomprising, at each said shared node: an index of block hashes to blockheaders for each of the plurality of distributed ledgers.
 10. The systemof claim 8, wherein each said shared node comprises a computer apparatuswhich comprises local node-stacks of said at least two distributedledger networks.
 11. The system of claim 8, wherein each said sharednode comprises local nodes for all of the plurality of distributedledger networks.
 12. The system of claim 11, wherein each said sharednode comprises a computer apparatus which comprises local node-stacks ofall of the plurality of distributed ledger networks.
 13. The system ofclaim 8, wherein an existing transaction in a source distributed ledgercontains a transaction output whose digitally-represented economic valueis to be transferred to a target distributed ledger.
 14. The system ofclaim 13, wherein a locking transaction spends the transaction output ofthe existing transaction, and wherein verification of the existence ofthe locking transaction in the source distributed ledger is necessaryfor a completing transaction in the target distributed ledger to spend atransaction output of an initiating transaction in the targetdistributed ledger.
 15. A system with cross-ledger transfers between aplurality of distributed ledgers for highly-scalable transactionthroughput, the system comprising: a set of computer apparatus, eachsaid computer apparatus comprising memory for holding computer-readablecode and data and one or more processors for executing saidcomputer-readable code so as to modify said data; communicativeconnections between each said computer apparatus and a plurality ofdistributed ledger networks; and computer-readable code for localnode-stacks of the plurality of distributed ledger networks at each saidcomputer apparatus.
 16. The system of claim 15, further comprising, ateach said computer apparatus: an index of block hashes to block headersfor each of the plurality of distributed ledgers.
 17. The system ofclaim 15, wherein an existing transaction in a source distributed ledgercontains a transaction output whose digitally-represented economic valueis to be transferred to a target distributed ledger.
 18. The system ofclaim 17, wherein a locking transaction spends the transaction output ofthe existing transaction, and wherein verification of the existence ofthe locking transaction in the source distributed ledger is necessaryfor a completing transaction in the target distributed ledger to spend atransaction output of an initiating transaction in the targetdistributed ledger.
 19. The system of claim 15, wherein the distributedledger comprises a blockchain.
 20. The system of claim 15, wherein thedistributed ledger utilizes a directed acyclic graph.